1. Field of the Invention
The invention is related to the field of communication systems, and in particular, to a communication system for communicating between a process and a destination.
2. Description of the Prior Art
With the expansion of client-server applications, the need for improved message handling between computers continues to increase. The Internet, object oriented programming, and distributed processing have also contributed to the demand for better message handling. Application developers use messaging Application Program Interfaces (API) to handle the messaging. Thus, the application developers only need a high-level understanding of the messaging and rely on the messaging API to handle the lower level messaging functions of the operating system.
One computer system called Tandem NonStop systems is a loosely-coupled parallel processor computer system designed to provide continuous availability for online transaction processing. This Tandem system uses a Guardian operating system. One feature of the Tandem computers is the Transaction Management Facility (TMF). If an error occurs downstream, the Tandem's TMF allows the transaction to be rolled back. This eliminates the need for error recovery code at multiple points in the system.
One messaging framework in the Tandem/Guardian environment is called NonStop Distributed Computing Environment (DCE). The NonStop DCE is a part of the Posix standard DCE. The NonStop DCE provides C functions for accessing services through a Remote Procedure Call (RPC) from one machine to a host machine. Another messaging framework is called Krypton. Krypton provides C functions for performing RMI similar to NonStop DCE. Krypton is available for Guardian, Unix, and Windows NT operating systems. Another messaging framework, Nonstop Domino (NS-DOM), provides C functions for invoking messaging services through the CORBA II API. One problem with the NonStop DCE, Krypton, and NS-DOM frameworks is the reliance on Interface Description Language (IDL) to generate functions. The developer must compile the IDL scripts through an IDL compiler to generate messaging functions.
Another prior art system called RMS shell, which was developed by Sprint Inc., handles messaging in Tandem computers. The RMS shell provides a messaging framework for creating client/server applications for the Tandem/Guardian environment. The RMS shell handles only one transport protocol to communicate between processes. The RMS shell posts and receives wait messages by specifying a pointer and length of the messages. When an originating process sends a wait message, the originating process waits for a reply from the target process instead of continuing processing. One problem with the RMS shell is the RMS shell only handles one type of transport protocol, process to pathway. One disadvantage is the RMS shell code is in C, a low level non-object oriented programming language. Those skilled in the art understand the benefits of object oriented programming languages such as maintenance and the ease of using objects to build applications. Another problem with the RMS shell is that it only correctly handles wait messaging, so the originating process must wait for replies. The RMS shell incorrectly handles no-waited messaging causing the RMS shell to drop transactions during high volume messaging. Another problem with RMS shell is that it only handles one type of message format.